CoreMark is a simple, yet sophisticated benchmark that is designed specifically to test the functionality of a processor core. Running CoreMark produces a single-number score allowing users to make quick comparisons between processors.
While anyone can upload a CoreMark score, certified scores have passed the rigorous analysis of the EEMBC Certification Lab.
Loading...
Our ULPMark suite now offers a CoreMark variant that clearly defines how to measure and record CoreMark power in a uniform way, making comparisons a snap!
EEMBC’s CoreMark® is a benchmark that measures the performance of microcontrollers (MCUs) and central processing units (CPUs) used in embedded systems. Replacing the antiquated Dhrystone benchmark, Coremark contains implementations of the following algorithms: list processing (find and sort), matrix manipulation (common matrix operations), state machine (determine if an input stream contains valid numbers), and CRC (cyclic redundancy check). It is designed to run on devices from 8-bit microcontrollers to 64-bit microprocessors.
How to port CoreMark, 2009
The CRC algorithm serves a dual function; it provides a workload commonly seen in embedded applications and ensures correct operation of the CoreMark benchmark, essentially providing a self-checking mechanism. Specifically, to verify correct operation, a 16-bit CRC is performed on the data contained in elements of the linked-list.
To ensure compilers cannot pre-compute the results at compile time, every operation in the benchmark derives a value that is not available at compile time. Furthermore, all code used within the timed portion of the benchmark is part of the benchmark itself (no library calls).
A more detailed explanation of CoreMark can be found in this whitepaper from EEMBC.
Like Dhrystone, CoreMark is small, portable, easy to understand, free, and displays a single number benchmark score. Unlike Dhrystone, CoreMark has specific run and reporting rules, and was designed to avoid problematic aspects of Dhrystone. For example, major portions of Dhrystone actually expose the compiler’s ability to optimize the workload rather than the capabilities of an MCU or CPU. Dhrystone is thus more revealing as a compiler benchmark than as a hardware benchmark. Likewise, library calls are made within the timed portion of Dhrystone. Typically, those library calls consume the majority of the time consumed by the benchmark. Since the library code is not part of the benchmark, it is difficult to compare results if different libraries are used. Finally, guidelines exist on how to run Dhrystone, but since results are not certified or verified, they are not enforced. There is no standardization on how Dhrystone results should be reported, with various formats in use (DMIPS, Dhrystones per second, DMIPS/MHz)
For a deeper dive into Dhrystone, checkout this analysis from the EEMBC Certification Lab in 2002.